Carlos Garnacho [Fri, 21 Nov 2025 13:46:03 +0000 (14:46 +0100)]
screenShield: Emit ::screen-lock-shown early with animated fades
If the screen is locked with animatedFade parameter enabled, the
screenShield currently defers the emission of this signal until the
lightbox toggles on. However the lightbox might be prevented from
ever doing that by later input.
If this emission is delayed enough, it will result in ShellDBus
missing the D-Bus timeout for replying to the Lock request, since
it does rely on this signal being emitted in order to reply back.
It does however make sense to keep setting the active state after
the animation, so the inhibitors are synchronized at the point the
lightbox kicks in.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8644
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3971>
(cherry picked from commit 7f84efb1edd652e55441c48af14d19d7d6b15b4e)
Florian Müllner [Thu, 20 Nov 2025 15:09:44 +0000 (16:09 +0100)]
swipeTracker: Immediately flip delta in RTL locales
The delta is currently flipped in a shared code path, after appending
the unmodified value to the event history. As a result, the calculated
final velocity for touchpad gestures is wrong in RTL locales.
Fix this by modifying the delta immediately when handling the events,
so that all other code operates on the correct values.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8840
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3967>
(cherry picked from commit a02835aacadbc14dc4350add3bae99c70e38f1b0)
Adrian Vovk [Thu, 1 May 2025 22:34:52 +0000 (18:34 -0400)]
main: Register session with GDM on startup
When no monitor is connected, gnome-shell starts but never emits
`startup-prepared` nor `startup-complete`. As a result, GDM never
detects that the shell has launched and plymouthd remains running,
preventing the system from reaching graphical.target.
Ensure that registerSessionWithGDM() is called even when no monitor
is connected, so GDM can terminate plymouthd and allow the system to
reach graphical.target properly.
Part of https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/285
We are currently still using eslint 8.x which has been unsupported
for quite a while. Update the ci-run-eslint script to a verison
that uses the supported eslint 9.x.
There's no reason why this is not the case, given that these tests are
running in completely separated environments, so they are safe to run in
parallel
overviewControls: Disconnect signals on destruction
While we are not getting errors and the ControlsManger is normally always
alive, during destruction we could still get events from other objects
that are still alive, so disconnect them all
workspaceThumbnail: Track later hiding drop placeholder
When closing the shell during a relayout we are getting this error:
(gnome-shell:2559407): Gjs-CRITICAL **: 06:57:21.765: Object St.Bin,
has been already disposed — impossible to access it.
This might be caused by the object having been destroyed from C code
using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x60991609b710 ==
#0 b resource:///org/gnome/shell/ui/workspaceThumbnail.js:1334 (5e050636fb0 @ 17)
#1 i resource:///org/gnome/shell/ui/main.js:279 (30c932d102e0 @ 119)
This is because the later we added is running even when not needed (e.g
when the placeholder is not visible already), but also because we may
run the later callback after the parent has been destroyed.
We (I) changed the test job to use a different path in commit 342d7ab34,
but the artifacts path was not adjusted :(
Fixes: 342d7ab34a ("ci: Start with a fresh build dir to ensure test dependencies are correct")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3945>
(cherry picked from commit 72b8c9044d9d8145014852ee2e7962396ff46ba2)
Sebastian Wick [Mon, 20 Oct 2025 11:38:37 +0000 (13:38 +0200)]
brightnessManager: Use slider as bias when auto brightness is being used
The code previously tried to ensure that the sliders were disabled when
auto brightness was active, and determine the brightness just from the
auto brightness target we get from g-s-d.
It turns out that users do want to still have some control over the
brightness, even if auto brightness is active.
The slider is now being used as a bias for the auto brightness target
instead.
This also means that we can drop the BrightnessScale::locked property.
Sebastian Wick [Thu, 30 Oct 2025 10:43:19 +0000 (11:43 +0100)]
brightnessManager: Propagate any attempted brightness change
The BrightnessScale was trying to be smart by not notifying changes of
its value when an action on it (stepUp, stepDown, cycleUp, set value)
resulted in no change.
It turns out that users do want to see an OSD even when their action
resulted in no change.
Always notify about attempted changes instead.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8770
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3941>
(cherry picked from commit aaef85ecbd558fec8aa138678fe859de930d42dd)
Alessandro Bono [Thu, 30 Oct 2025 10:47:17 +0000 (11:47 +0100)]
loginManager: Use systemd session auto object to get session ID
Relying on the Display property is buggy when the gdm user spawns more than
one gnome-shell instance.
```
$ loginctl
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
11 42 gdm - 11778 manager-early - no -
c20 42 gdm seat0 34313 greeter tty1 yes 17h ago
c21 42 gdm - 34938 greeter - no -
c22 42 gdm - 35693 greeter - no -
```
From the logs:
```
$ journalctl -b | grep "Will monitor"
[...]
Oct 29 15:14:59 gnome-shell[34961]: Will monitor session c20
Oct 29 15:22:57 gnome-shell[35716]: Will monitor session c20
Oct 29 15:22:58 gnome-shell[35716]: Will monitor session c20
```
Use the systemd session auto object for getting the session id. We can't return
directly the session proxy created from it because it won't emit signals. From
the documentation[1]:
```
Signals are only emitted on objects referencing a specific session ID not on the
"/org/freedesktop/login1/session/self" or "/org/freedesktop/login1/session/auto"
convenience objects, as they can only be dereferenced relative to a method caller.
```
Sebastian Keller [Wed, 29 Oct 2025 10:09:02 +0000 (11:09 +0100)]
osk-layouts: Drop comma key from de-extended and at-extended layouts
The row containing that key was one key too long, which was causing
misalignment. The comma key is not shown in the us-extended layout
either and is available via long press on the dot key or via ?123,
making it the best candidate to remove from these layouts.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8756
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3940>
(cherry picked from commit f076b775bbbe1f73307311c3c971ca8a12e67bf3)
The commit was causing freezes when changing layouts in some situations
and not all of these were adressed by f643915b, such as when switching
from the 3rd to the 4th layout using a xkb shortcut in the X11 session
with 4 layouts.
It was also breaking the order of switching layouts using modifier-only
xkb shortcuts to switch to the next group, which it caused to advance
multiple groups because of the shortcut being handled via both
_modifiersSwitcher() and _layoutGroupChanged().
Further it was possible for _layoutGroupChanged() to trigger an error
due to the locale layout added by _buildGroupStrings() at the end of the
xkb layout list being accessible via the xkb shortcuts. That layout was
not present in _inputSources, leading to "is" being undefined.
Florian Müllner [Tue, 21 Oct 2025 18:12:59 +0000 (20:12 +0200)]
tools: Symlink node_modules in project root
NPM assumes quite strongly that it manages the project as a
whole and its package/lock files are located in the project
root.
While we somehow managed to keep the npm tooling in a subfolder,
this comes at the cost of breaking imports of additional modules.
This will become relevant when we update eslint to a supported
version, as we want to keep using the `junit` formatter in CI,
which has now been split out into a separate module.
So bite the bullet and make the node_modules folder available in
the project root.
On the plus side, having the node_modules folder in the project
root allows language servers in IDEs/editors to pick it up.
Florian Müllner [Thu, 23 Oct 2025 12:06:08 +0000 (14:06 +0200)]
tools: Pin git node modules
Both changes in the config (like new/changes rules) and the eslint wrapper
(like updating to eslint 9.x) could require changes on the shell side, and
therefore require conscious update rather than randomly breaking the CI.
Sebastian Keller [Sat, 25 Oct 2025 11:03:55 +0000 (13:03 +0200)]
keyboard: Don't move window when it got unmanaged during shift animation
When a window with a text-entry at the bottom that had triggered the OSK
and was shifted up to avoid overlapping the OSK is closed right after
losing keyboard focus, this results in a crash. The focus loss triggers
the animation to move the window actor back into its original position,
which moves the underlying window when finished. That however will fail
when the window has been unmanaged and some of the underlying resources
have already been destroyed while the animation was playing.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8752
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3933>
(cherry picked from commit 4900aad2deab7398e69b1a57a38285fa73974c0f)
Florian Müllner [Tue, 21 Oct 2025 22:57:26 +0000 (00:57 +0200)]
systemActions: Don't log error when cancelled
If the logout/reboot/shutdown actions are available, we expect them
to succeed. Unfortunately that changed in the light of systemd
inhibitors (that we don't know about in the shell, and that prevent
those actions now).
While it would be good to fix the underlying issue, we can at least
improve the error reporting in that case and not log the error when
the operation was cancelled: We don't know the underlying reason,
unlike gnome-session which should have logged a more helpful message.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8749
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3927>
(cherry picked from commit d3f3f4e80d338133a2083dd5c267ed456b86303d)
The child watch source is the only thing that reaps the child process.
We cannot remove it until it fires or the child will remain a zombie.
So, just leave the source attached. Trying to remove it does not seem
easy, and I don't see any need; we expect the child process to exit
quickly, so this doesn't seem harmful.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7083
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3926>
(cherry picked from commit 961a7d721f3e4db9be6df958b10ba98955138cae)
Sebastian Keller [Sun, 19 Oct 2025 16:47:31 +0000 (18:47 +0200)]
dnd: Don't try to connect to transition when animations are disabled
When animations are disabled, the ease has finished before the
get_transition() call, causing the latter to return null, which will
result in an error message when connected to.
Antoine Lassagne [Fri, 10 Oct 2025 12:55:40 +0000 (14:55 +0200)]
status/network: Update indicator icon on connectivity changes
When there is no active main connection or it uses a device type we do
not handle, the indicator icon and its visibility depend on the global
connectivity.
However we currently don't update the icon on connectivity changes,
with the result that we sometimes show the fallback connection icon
when the network is in fact disconnected.
To fix this, update the icon whenever the (global) connectivity changes.
Florian Müllner [Wed, 1 Oct 2025 18:19:14 +0000 (20:19 +0200)]
messageList: Make media messages follow notification policy
Unlike regular notifications, media messages are shown unconditionally
for any active MPRIS player. In the past that was uncontroversial, but
now that media messages are shown on the lock screen as well, there is
a privacy concern.
To address this, make media messages follow the notification policy
of the corresponding app (if specified) or the general notification
settings.
messageTray: Never close a notification banner that is about to show
If a new notification is pushed (or the same is updated) in a very short
time GNOME shell may only show the last notification (or none).
This is because since commit 2801d0bf a notification that is about to
show (so in SHOWING state) may be considered expired, given that the
notification timeout won't be set until the show animation has
completed.
Thus, only consider the notification as expired when the notification is
in the shown state, but not in the showing one.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6529 Fixes: 2801d0bfe3 ("messageTray: Close SHOWING banner when its notification is destroyed")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3905>
notificationDaemon: Do not send activation event multiple times
When a FDO notification is updated we reuse the previous instance,
however we do not care about disconnecting the default activation signal
and thus we may end up emitting the same multiple times, even in the
case the updated notification has no action at all.
Carlos Garnacho [Tue, 30 Sep 2025 14:09:47 +0000 (16:09 +0200)]
status/keyboard: Track ::layout-layout-group-changed for changes
This may happen under the hood without UI interaction through modifiers
expressed in xkb-options to switch to specific layouts. Make this
actually have an effect in the UI bits, and update the selected layout
if these changes happen without further GNOME Shell involvement.
The end session dialog is now using a new style for the warning messages
but this style is not re-used by other dialogs that have messages with a
similar role.
So be consistent, and use same style for all the dialogs that are
showing a warning or an info message, and in particular
- Keyring dialog error messages
- Polkit dialogs error and info messages
- Conflicting dialog warning message
Daniel van Vugt [Fri, 26 Sep 2025 06:36:41 +0000 (14:36 +0800)]
st/theme-context: Warn instead of crashing on unsupported accent colors
For example, Ubuntu's "brown". This is patched into gnome-shell for Ubuntu
but if you forget the patch then it's not worthy of a crash. Just pick a
colour and issue a warning.
notificationDamon: Always send the activation token
In case of FDO notifications, we may receive a notification coming from
non-desktop-applications (e.g. gsd does that), but in any case when
activating an action we should always provide back the activation-token.
So send the startup notification ID in any case, even if the appId is
unset (in fact get_startup_notify_id() uses a nullable parameter for a
reason since GNOME/glib@6210708f).
In wayland this more than enough, while in X11 we could have used the
gnome-shell desktop file as fallback, but that's gone for good now!
Noam Raz [Wed, 24 Sep 2025 08:49:43 +0000 (11:49 +0300)]
overviewControls: Ensure ws thumbnails are expanded before fading in
The current logic in `_updateThumbnailsBox` updates the expand fraction
only after the fade animation completes, rendering the fade-in
transition broken: the thumbnails fade in, but they have a height of 0
until after the animation, when they jarringly "pop" into place. This
abrupt transition is observable when exiting search in the overview with
multiple active workspaces.
Instead, split up the logic a bit to make sure the thumbnails always
appear fully-expanded during the animation: when animating in, the
`expand-fraction` is set _before_ the animation starts, and when
animating out it is set after.
This logic should make all workspace thumbnail state transitions behave
correctly:
- The thumbnails still expand/collapse smoothly when `should-show`
changes because `_updateThumbnailsBox` is called only when that
transition completes.
- Transitions into/out of search just fade the thumbnails because they
are always expanded during the animation.
- https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7668 is avoided
because `expand-fraction` is still set to 1 by `_updateThumbnailsBox`
when revealing the thumbnails.
- The thumbnails still have an `expand-fraction` of 0 when hidden,
carrying over the fixes from 9bf550da8 ("overviewControls: Set
expandFraction for ws thumbnails to 0 when hidden").
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7985 Fixes: c576f82bd ("overviewControls: Make sure thumbnails expandFraction is bound to visibility")
Part-of: <https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3888>
gdm/authPrompt: Fix key focus handling on choice list
When a choice list widget is prompted in GDM we call updateSensitivity()
but this does not act on the currently visible authentication widget but
rather on the text entry all the times.
And this causes that when a choice list is shown we always set the key
focus to the (hidden) text entry.
This implies that when the list is finally shown, moving the arrow keys
leads makes the entry context menu to be shown instead of being able to
navigate through the entries.
So, make updateSensitivity use the currently visible authorization
widget instead and use it to control the sensitivity of the choice list
As per previous change we now rely on a GLib version in which GioUnix
DesktopAppInfo implementation provides all the methods, so let's bump
the glib (actually gio) dependency for that.
As we need to be sure that the shell's typelib is rebuilt against newer
Gio, or updating GLib before than the shell would break us.
projects / gnome-shell.git / log